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Software is Not 


Dependable 


* For most people, software 
- behaves unpredictably and inexplicably 


- fails often 

- feels insecure, corruptible 

- appears unreliable and shoddy g 
e Unhappy state of affairs 


- novelty is wearing off 
- day-to-day tool, not new toy 
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Good design is difficult 

— no proven, teachable methodology 
Producing error-free code is hard 

- PPRC's focus 

Minor mistakes have major consequences 
- system architecture is not resilient 


Testing is not systematic 
- but no other general alternative to reduce errors 


Culture emphasizes measurable aspects 
- performance 
- features 


Improving Software 


Technology 


Fundamental technologies 
- programming languages 
- programming tools 
system architecture and programming model (OS/RT) 


Steady, incremental improvement in each field 


Major improvements cross discipline boundaries 
- legacy and narrow focus constrain progress in each area 


Example: correctness tools 

- languages difficult to analyze soundly 

— specifications not part of code 

- programs run in open and porous environments 


* Could we build better software if we start afresh? 
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Can we build systems that are resilient against 
programmer faults? 


How would software development evolve if 
dependability was primary goal? 


Can we accelerate progress in software by 
attacking problems from several directions? 
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What technology will MS need to build dependable 
software? 
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Use managed code throughout to reduce errors 
and virtualize instruction stream 


Constrain language and programming model to 
favor verification 


Close execution environment to facilitate 
compilation and program analysis 


Introduce strong process isolation to minimize 
consequence of programmer faults 


Make communication explicit and carefully 
checked 
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* Programming Language and Tools 
(Larus) 


e Compiler and Runtime Environment 
(Zorn) 


* Application Domain & Validation 
* Conclusion 
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* Benefits 
- improved verification and analysis for code reliability 
- strong fault containment for application reliability 
- strong application specification for system reliability 
- fixed process identity for security 
— optimization of whole processes for performance 


* Research opportunities 
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Managed code doesn't provide isolation or fault containment 


Strong process isolation model 
— no shared memory between processes 

- no dynamic code loading, process sealed at creation 
Singularity process 

- Isolated object space with threads 

- unit of failure and termination 

- unit of security policy enforcement 

- unit of system extension 

— target for complete optimization 

Is not 

- address space 

— extensible once started 


Scheduler IPC Manager VO Manager 
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* Strong process isolation model 
— no shared memory between processes 
- no dynamic code loading, process sealed at creation 
* Singularity process 
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- unit of security policy enforcement 
- unit of system extension 
— target for complete optimization 
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Processors and Other Hardware 


* Explicit communication model 
- all communication through channels typed by contract 
— contract defines types and patterns of messages 


e Singularity channel 
- bi-directional, asynchronous message transport 
- accessed through exactly two endpoints 
- moved by placing endpoint in a message 


* Is not 
- movable except in statically verified state 
— accessible after endpoint has moved 
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Kernel Runtime 


Application 


Application 
Runtime 
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Channel 
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Administration and 


Maintenance 


* Ubiquitous metadata 
- administration policies described in declarative metadata 
- setup and patching are OS, not application, responsibility 


* Singularity application abstraction 

rst-class OS abstraction describing an application 

- statically described in an application manifest 

- complete descriptions of entire system (including kernel) 
- basis for installation and maintenance 

- dynamically exposed for introspection 


o Security 


* Orthogonal administration of isolated applications 
- application isolation instead of virtual PCs 


* Singularity process-based security model 
— fixes identity at creation time [code,user,machine] 
- arbitrates process creation 
- arbitrates channel endpoint propagation 
- supports absolute process content privacy 


* Model does not 
- use CLR code access security 
— provide security granularity smaller than process 
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e Singularity OS (Hunt) 


* Compiler and Runtime Environment 
(Zorn) 


* Application Domain & Validation 
* Conclusion 


* Spec# 
- superset of C# developed by FSE and SPT groups 
— pre-/post-conditions & invariants 
* statically verify subset 
* runtime assertions and test case generation 
- vehicle for language experimentation 
* evolve language with tools 


* Conformance checking 
- behaviorally typed message passing channels 
- ensure client/server code obeys channel protocol 
- modular checks lead to global deadlock freedom 


Language Research 


Goals 


* Language to support reliable software 
- focus on problematic aspects of programming 


- balance static verification and runtime 
mechanisms 
* completeness/precision 
* expressiveness/late notification 


* Test new features against realistic, but 
manageable code base 


e Basis for Java/C& successor 


* Error handling 
- lightweight transactions to restore state 
— static checking of explicit restore code 


e Concurrency 
— atomic block identifies unit of concurrent update 
- enhanced types identify shared data 
— optimistic & pessimistic implementations 


* Modularity 


- functions & classes are mechanism for building 
abstractions 


- need better large-grain mechanisms (modules) 
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Build on research in SPT, FSE, and TVM groups 


Boogie extended static checker for Specs 
— sound 

- object invariants 

- annotation inference 


Zing model checker 
- targeted at language verification 
- used in a variety of concurrency-related tools 


Test generation tools driven from Specs 
annotations 
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Zing model checker 
- targeted at language verification 
- used in a variety of concurrency-related tools 


Test generation tools driven from Specs 
annotations 


Managed code tools from PPRC 


* Accelerate co-evolution of languages and 
tools 


e Employ tools throughout entire project 
lifetime 


e Scale tools from components (e.g. drivers) 
to systems 


* Identify opportunities for new tools and 
build them 


Formal design 
— modeling tools for critical aspects of system 
— formal specification, simulation, and verification 


Correctness 

- continue research 

Security & privacy 

- beyond exploits to system-level problems 
— information flow 

- runtime monitoring 

Testing 


- static analysis to increase test effectiveness 
- usage profiles 
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* Conclusion 


Compiler and Managed 


Runtime Environment 


* Big bets 
— merging OS and managed code runtime 
- limits on functionality benefit performance and 
correctness 
* e.g., no dynamic code loading 
- real-time and kernel garbage collection 


* Managed Runtime Environment (MRE) 
- IL; architecture neutral instruction set 
- base class library: collections, 1/0, etc. 
— services: garbage collection, reflection, .. 


* Existing MREs designed for applications, not 
system 
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e Compiler 
- produce high performance managed system 
- integrate types into lowest levels of system 


* Runtime 
- make GC suitable for kernel 


- exploit runtime to improve correctness and 
performance 


- rethink runtime services (e.g., reflection) 
- customize MREs for application domains 


Compiler Research 


e Typed assembly language (TAL) 
create a TAL suitable for OO languages 
- also suitable for MRE/OS low-level implementation (GC) 
- show MRE + application program is still type safe 
* e.g.: program type safe after inlining runtime type test 


* Optimization 
- whole program: take advantage of process sealing 
- cross-process (system-level) optimization 
* e.g.: channel communication 
* New language features 
- e.g.: transactions 


* GC in kernel 
- exploit MM info to increase GC locality 
- integrate GC with scheduling for real-time apps 
- support multiple GCs for diverse app requirements 


* Use runtime to enhance correctness 

— GC has global view of heap connectivity 

- sampling can collect arbitrary runtime info 
* Rethinking runtime 


- move reflection to earlier time (e.g., loading) 
- defining MREs as unit of abstraction 


* Build on research in ACT and RAD groups 


* First compiler / MRE based on Bartok 
- optimizing MSIL to native code compiler 
- lightweight runtime system 
- runtime and compiler written entirely in C# 


. ongoing runtime locality and correctness 
researd 
- hot data streams 
- statistical error detection 
- runtime data collection and sampling 
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* Programming Language and Tools 
(Larus) 


e Compiler and Runtime Environment 
(Zorn) 


* Platform for home services 
multiple, interacting application 
- zero maintenance / remotely administered 


/ recover and ci 


Home services 
- video/audio server (Tivo) 

- backup (Miva) 

- home automation 

- communication/collaboration (Exchange) 
Alternative to single-functlon appliances 
- lower fixed cost 

- better integration 
- lower barrier for in 


ntinue after failure 


(Wang vs 
Infrastructure for software as service 
TAB suggestions are very welcomed (want a device for home?) 
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* June 200: 
— simple Singularity kernel with threads and channels 
- Bartok runtime system on bare metal 
- type safe device drivers and PnP support 
- Spec# compiler generating MSIL 


* September 2004 
- Spec# extensions 
- real-time scheduler 
- more device drivers 
- services (name service, file system) 
- processes and more efficient threads and channels. 
- application abstraction (metadata) 


* December 2004 
— first application deployment to home machines 


Imperative to develop tools and technigues to 
build dependable software 


Dependability reguires Masone synergistic 
changes in languages, tools, and system 
architecture 


Singularity deliverables: 

specification and modeling tools 
verifiable programming languages 
program correctness tools 

real-time managed code system 

strong isolation OS 

self-descriptive system and applications 
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